Wir sitzen in einem großen Hörsaal einer Frankfurter Hochschule, die Sitzreihen sind leicht ansteigend, damit alle Studenten nicht nur hören, sondern auch gut sehen können. Ungefähr 150 Zuhörer – zum Großteil keine Studenten - hören dem Referenten zu, keinem Professor, sondern einem dynamisch wirkenden Gründer und Manager eines norditalienischen Start-up. Er berichtet darüber, wie er mittels Bildauswertung Anomalien auf der Haut des Menschen mit Hilfe mathematischer Methoden auswertet. Er gibt diese Erkenntnisse mit viel Herzblut wieder und wird prompt gefragt, welche Machine Learning Algorithmen er einsetze.

Wir befinden uns in einem Data-Science- und Artificial Intelligence- (AI) Meetup in der Frankfurt School of Finance, einer tollen Location in Frankfurt am Main, die diesen Hörsaal und die Facilities einer modernen Hochschule bereitstellt, damit Menschen mit gleichen Interessen sich austauschen, treffen und diskutieren können - vielleicht sogar neue Jobs finden. Das ganze Szenario wird angereichert durch interessante Vorträge von Start-up Firmen. Wenn es auch nicht immer um real im Business so einsetzbar ist, was wir da hören, ist es aber in jedem Falle anregend, motivierend und macht Lust auf mehr.

Data Science und AI Meetup in der Frankfurt School of Finance

Neben mir lauscht ganz interessiert ein junger Teamleiter einer Bank den Ideen des Start-up-Gründers. Wir kommen ins Gespräch und stellen fest, dass das daily Business dieses Bankmanagers ihn zu folgendem Gedanken treibt: „Wenn ich es schaffe, die guten Ideen der KI Themen in meiner Bank umzusetzen, in welcher Infrastruktur und in welchem Umfeld muss ich das tun, sodass mein Geldgeber dieses Projekt freigibt und mir den Weg nach oben öffnet?“

Er teilt mit mir mehr seiner Gedanken: „Ich muss es hinbekommen, in meiner Bank eine Gruppe von 15 oder von mir aus auch 50 Data Scientists und Programmierer miteinander arbeiten zu lassen und zwar hocheffizient. Was heißt hocheffizient? Dies bedeutet, diese Programmierer profitieren voneinander. Hocheffizient bedeutet, diese Programmierer bringen ihren Code und ihre intellectual property schnell in Produktion, das heißt es existiert ein schnelles Deployment von der Entwicklung über Tests in die Produktion.“ Und weiterhin müsse die Infrastruktur ihnen die Möglichkeit in der Entwicklung bieten, sehr schnell auf vorhandene Programme zuzugreifen.

Zugleich denken wir gemeinsam darüber nach, ob wir es schaffen können, in einer Bank weitestgehend unabhängig von langwierigen IT-Prozessen, eine Infrastruktur zu nutzen, die es ermöglicht, dass die Gruppe von Programmierern und Data Scientists eine elastische Umgebung bereitgestellt bekommt.

Elastizität im Asset Management

Elastizität bedeutet zum Beispiel im Asset Management von institutionellen Fonds, dass im Bereich Research im Oktober und November eine große Anzahl an Cores benötigt werden, um Simulationen mit neuronalen Netzen durchzuführen, während in den anderen Monaten des Jahres die zur Verfügung gestellte Infrastruktur und Leistung eher niedrig gehalten wird. Diese Elastizität erhalte ich in meiner Gruppe von Data Scientists und Programmierern durch eine Cloud-Infrastruktur. Aber nicht nur durch die Infrastruktur selbst, sondern auch durch elastische Preismodelle, die mir dieses „Atmen“ ermöglichen.

Das heißt, ich muss mir neben dem Business-getriebenen Ansatz, der meine KI Use Cases inklusive Machine Learning-Algorithmen auf Sinnhaftigkeit und Wertbeitrag prüft, eine ideale IT Infrastruktur für meine Gruppe schaffen, damit die IP dieser Gruppe schnell, effizient und elastisch umgesetzt werden kann.

Diese Infrastruktur beinhaltet zwei entscheidende Perspektiven. Die erste Perspektive ist eine IT-lastige und widmet sich der idealen Basis-Architektur für mein KI-Vorhaben. Die zweite Perspektive greift die Fragestellung auf, wie ich unterschiedliches Wissen in Sachen Modellierung und die Lebenszyklen der mathematischen Modelle integriere. Dazu benötigen wir die völlige Freiheit in der Wahl der Programmiersprache – natürlich inklusive Python, R, aber auch SAS. Diese Infrastruktur muss es mir ermöglichen, mein Jupyter Notebook, mein R Studio oder auch Visual Data Mining and Machine Learning von SAS zu verwenden – je nach Ausbildung, Vorliebe und Ausprägung meiner Skills.

Model Management

Weiterhin habe ich an die Infrastruktur die Erwartungshaltung, dass ich zahlreiche Modelle – entwickelt in der ganzen Gruppe über mehrere Monate hinweg – verwalten, steuern und monitoren kann. Dieses
Modell-Management wird unerlässlich, so lange ich mich nicht in dem kleinsten Rahmen von nur wenigen Entwicklern und wenigen Data Scientists und auch wenigen Modellen bewege.

Und für das fachliche Enablement kann sogar der Gastgeber, die Frankfurt School of Finance, beitragen. Hier kann ich mich zum zertifizierten KI-Advisor ausbilden lassen. Für die Infrastruktur bietet sich für Programmierer und Data Scientists eine containerbasierte Cloud Umgebung an. Die Container ermöglichen es mir, sehr schnell Programme in Produktion zu bringen oder zu vervielfältigen, um damit eine effiziente Kollaboration zwischen den Programmierern sicherzustellen.

Aktuell gibt es kaum eine Bank im Raum Deutschland, Österreich und die Schweiz, die in ihrer Strategie nicht den Einsatz container-basierter Technologie zumindest gerade evaluiert. Einige Banken haben Container und den Einsatz von Cloud auch bereits als Strategie ausgerufen. Diese Strategie prallt dann aber auch nicht selten auf die Realität: Bei zum Beispiel über 10 Jahre gewachsenen Datenstrecken, die sich auf Großrechnersystemen befinden  – ja, das finden wir in der deutschen Bankenlandschaft heute noch – ist die Migration in eine Cloud-Technologie noch vergleichsweise einfach (Je nachdem, ob ich in einem Lift-und Shift-Ansatz 1:1 in die Cloud migriere oder in einem Re-Factoring Ansatz die Möglichkeiten einer Cloud in die Ziel-Applikation mit hinein implementiere).

Aber die über Jahre im Sinne der Performance optimierten Datenstrecken und ihre Abhängigkeiten – zum Beispiel in den Jobketten – in eine Containerwelt zu migrieren, bedarf einer vorgeschalteten Mehrwertbetrachtung.

Es kann zum Beispiel sehr sinnvoll sein, eine gewachsene Datenmanagement-Welt mit über 80 Applikationen – von der monatlichen Personalstatistik bis zum Geldwäsche-Bekämpfungssystem – in mehreren Schritten in eine neue Infrastruktur zu überführen, indem ich erst einmal eine GRID-Technologie einführe, die mir für diese traditionell entwickelten Systeme das Workload-Balancing, die Prioritätenregelung der Jobs und die Ausfallsicherheit garantiert. Parallel kann ich neue Anforderungen des Business in einer containerbasierten Welt entwickeln und in einem Dreijahresplan - Job für Job und Applikation für Applikation - aus dem GRID in die neue Container-Infrastruktur migrieren.

Einige Banken haben Container und den Einsatz von Cloud auch bereits als Strategie ausgerufen. Diese Strategie prallt dann aber auch nicht selten auf die Realität. Click To Tweet

Und jetzt wird es wichtig, mir für diesen Ansatz die richtigen Instrumente auszuwählen, das heißt, die richtige Software-Rezeptur oder Plattform. Idealerweise harmonieren meine traditionellen Applikationen mit den neuen containerbasierten Applikationen, indem sie auf einer einzigen Plattform-Basis aufgesetzt sind, ohne mir dabei die Flexibilität zu nehmen, diese Plattform auch zu verlassen.

Meetup

In unserer durch diese Gedanken angereicherten Diskussion auf dem Meetup in der Frankfurt School of Finance einigen wir uns darauf, dass ich in Summe einen kleinen Zauberwürfel vor mir habe, der mir vielleicht sechs unterschiedliche Farben oder Eintrittstüren aufzeigt.

Diese unterschiedlichen Eintrittstüren oder Komponenten in meiner Entscheidung der Plattform meiner Arbeitsgruppe in einer Bank sind die folgenden: Erstens, welche Use Cases besitze ich im Rahmen eines Business Ansatzes, um Machine Learning-Verfahren einzusetzen und einen Benefit für meine Bank zu generieren?

Zweitens, welche Infrastruktur stelle ich zur Verfügung, damit meine Gruppe von Programmieren und Data Scientists miteinander kollaboriert, sich untereinander austauscht und voneinander profitiert? Drittens, welche Beschaffungszyklen plane ich ein, um meine Gruppe mit Infrastruktur zu versorgen, oder anders gesprochen, wie schnell kann ich diese Infrastruktur in einer Cloud-Umgebung zur Verfügung stellen - mit der Perspektive den Cloud-Anbieter jederzeit wechseln zu können? Viertens, wie schnell bringe ich die Erkenntnisse und Ergebnisse meiner Data Scientists über eine Entwicklung oder einen Test in die Produktion der Bankprozesse? Fünftens, wie ermögliche ich Neueinsteigern den Zugang zu dieser Plattform - das heißt konkret, wie schnell lernen die Neueinsteiger die vorhandenen Prozesse und Tools? Sechstens beschäftigt mich die Frage: Möchte ich die Plattform, die ich benötige, selbst designen und entwickeln und welchen Aufwand handele ich mir damit ein? Oder möchte ich eine Halbfertigware einkaufen von Plattform-Anbietern, die es ermöglichen, Data Science Workbenches, Container Technologie, Cloud und den entsprechenden Support aus einer Hand zu beziehen?

Mit diesen anregenden interessanten Gedanken verlasse ich das Meetup  am späten Abend, um auf meiner Heimfahrt weiter darüber nachzudenken, wie es dem jungen Teamleiter der Frankfurter Bank in den kommenden Wochen und Monaten in seinen Projekten ergehen wird.